1. Field of the Invention
This invention relates generally to data transfer interfaces, and more particularly to a port independent data transaction interface for multi-port devices.
2. Description of the Related Art
Multi-port architectures currently are available that allow multiple client devices to communicate to a single device. For example, a conventional multi-client semiconductor memory system includes one or more client devices connected via a bus to a memory controller, which manages data flow to and from the client devices to a memory. Interfaces, or protocols, are used to define communication with the conventional multi-port architectures, as illustrated in FIG. 1A.
FIG. 1A is a block diagram showing a prior art multi-port interface 100. In this example, the multi-port interface 100 defines an interface for a conventional multi-port memory controller 102, and includes a command channel 104, and data-in channel 106, and a data-out Channel 108. The command channel 104 is utilized to provide commands to the memory controller 102, such as read and write commands. The data-in channel 106 is utilized to provide write data to the memory controller 102. For example, when a write command is received on the command channel 104, the data to be written to memory is provided on the data-in channel 106. The data-out channel 108 is utilized to provide data to the requesting device. For example, when a read command is received on the command channel 104, the data read from the memory device is provided to the requesting device on the data-out channel 108.
Unfortunately, the conventional multi-port interface 100 tightly couples the data with the corresponding commands, as illustrated in FIG. 1B. FIG. 1B is a block diagram showing an exemplary prior art multi-port memory architecture 110. The prior art multi-port memory architecture 110 includes a multi-port memory controller 102 coupled to a memory device 114. Coupled to each port of the multi-port memory controller 102, is a source device 112a–112c. As will be appreciated by those skilled in the art, the multi-port memory controller 102 facilitates communication between each source device 112a–112c and the memory device 114.
To interact with the memory device 114, each source device 112a–112c transmits a command to the multi-port memory controller 102, such as a read or write command. In addition, the source device 112a–112c generally must send any data associated with the command, such as data to be written to memory, along with the command to the multi-port memory controller 102. Further, the data generally must be in one of a plurality of predetermined lengths. When data expected to be associated with the command is not provided with the write command, the memory controller 102 generally stalls this command and goes on to the next command from another port. This activity stalls all requests on the original port until the data for the write is received. When the prior art memory controller 102 receives data without a corresponding command, the controller generally views this as an error condition and the transaction is nullified somehow. Thus commands and data are tightly coupled in prior art multi-port interfaces.
For example, to write data to the memory device 114 using source device 112a, source device 112a provides a write command along with the corresponding data to the multi-port memory controller 102. The multi-port memory controller 102 then interprets the write command and writes the corresponding data to the memory device 114 at the memory address specified in the received write command. Thereafter, the write transaction is completed and the multi-port memory controller 102 can accept the next command from the same or another source device 112a–112c. 
Similarly, to read data from the memory device 114 using source device 112b, source device 112b provides a read command to the multi-port memory controller 102. The multi-port memory controller 102 then interprets the read command and reads data at the memory address specified in the read command from the memory device 114. Next, the multi-port memory controller 102 provides the data received from the memory device 114 to the source device 112b. Thereafter, the read transaction is completed and the multi-port memory controller 102 can accept the next command from the same or another source device 112a–112c. 
As illustrated by the above examples, prior art multi-port interfaces require each transaction to be fully completed before the next transaction can begin. That is, once a transaction is begun, the transaction cannot be interrupted to start a new transaction until the first transaction is completed. For example, during the above read operation, the memory device 114 generally requires several clock cycles to complete the read operation. Thus, the memory controller 102 is idle for several clock cycles, during which the memory device 114 accesses the requested data. Unfortunately, prior art multi-port interfaces do not allow the memory controller 102 to begin processing a command from another source device 112a–112b during this idle time. As a result, the prior art multi-port interfaces generally to do not support fully pipelined architectures wherein data is being processed each clock cycle.
In view of the foregoing, there is a need for a data transaction interface that allows fully pipelined data processing for multi-port devices. The data transaction interface should allow for decoupling of data and corresponding commands, and should further allow for arbitrary data lengths and arbitrary starting address locations. Moreover, the data transaction interfaces should allow transactions to have different priorities, thus allowing higher priority transactions to interrupt prior received lower priority transactions.